自動テスト、夜間ビルド、非常に俊敏性。 製品のテスト方法

私たちのテストは素晴らしい製品であり、期限が厳しく、大きな責任があります。



各企業は、作業プロセスの組織について独自の見解を持っています。 そして、それらは非常に異なる場合があります。



今日は、製品のテスト方法についてお話します。 おそらくあなたは何かと議論するでしょうが、何かを奉仕するでしょう。



当社の製品は、多数のモジュールで構成されています。 これらは定期的に更新され、これらのアップグレードは完全なミニ製品です。



開発者は、別のバージョンでコードのパックを収集します。 そして、彼らは説明を書きます。「 クラウドの新しいオンラインストア。 変更はそのようなものです。 たくさんの新しいページを追加しました 。 " そして、数百のコミットを含む巨大な変更ログを必ず適用してください。



これはすべてテスターに​​送られます。 このプロセスを「極端なアジャイル」と呼びます-明確な反復に取り組んでいます。 これらのテストルールから逸脱することはできません。



これは必要な措置です-製品は巨大であり、その変更も同様です。 そして、テストを遅らせないために、特定の自由を犠牲にします。



更新を確認するタスクを受け取ったら、テスト計画を確認します。 モジュールごとに個別に設計されています。 計画には、すべての重要な使用シナリオがリストされています。



以前はこれを行っていました。 前例の詳細な説明を作成しました。 パスワード入力フィールドに円が表示されます。 表示されない場合、何かが間違っています。」



先例の数がすべての合理的な制限を超えた場合、この慣行を放棄しました。



その結果、テスト計画は重要なビジネスシナリオのリストであるという結論に達しました。



例は、Bitrix24でタスクを操作するためのケースのリストです。



-タスクの保存は機能しますか？ よし、進みましょう。

-タスクにコメントが追加されますか？ 素晴らしい、次の段落。



まず、最上位の主なシナリオから始めます。たとえば、ストアオーダーの作成と保存です。 そして、レベルの低いシナリオに進みます-たとえば、タスクの期限の正しい作業。



次に、システムアクションの実行方法をいくつかの段階で確認します。

テスト手順

最初に、特定のモジュールに対して自動テストを実行します。 それらすべての有益なモジュールを実行します。



自動テストの実行と並行して、次のことを行います。

ステージ1

-開発者による変更の説明を調査します。



参照の観点からそれがどうあるべきかを検討します。 実際のモジュールの作成方法と比較してください。 しかし、最も重要なことは、常識と平均的なユーザーの観点から製品と変化を見る方法を学ぶことです。



作業スクリプトは便利ですか？ すべてが「人間的に」行われていますか？ 同時に、ユーザビリティテストも実施しています。



これは常に機能するとは限りません-膨大な数の変更。 しかし、いつでもシナリオをより便利にすることができるのかを開発者に伝えています。



ルーチンの大部分を自動化しました。 そして、私たちは常に「引き締める」ことができると考えています。



開発者向けの質問については、アップデートごとに個別のチャットで議論します。 「壊れた電話」はありません。リリースに関係するすべての従業員がチャットに参加しています。

2段階

そのため、更新の説明を検討し、変更のログを読み取りました。これは第2段階です。



-この段階では、ほとんどのエラーを「キャッチ」します。 開発者は「通常」の説明に何かを見逃すことがありますが、変更ログにはすべてのエラーが表示されます。



最近好奇心がありました。 開発者は、製品のローカライズバージョンのテキストに変更を加えました。 フランス語で。



それは単なるテキストのように思えます。 しかし、このトリッキーな組み合わせにはアポストロフィがありました。 その結果、テストの特定の段階で、JavaScriptが落ち始めました。



システムは、この組み合わせの処理方法を知らないだけであることが判明しました。 しかし、変更の著者は説明で彼について言及しませんでした。 変更ログを慎重に調査した結果、間違いを発見しました。

3段階

次に、第3段階が始まります-製品エラーに対する顧客のリクエストの分析：



ヒットはマンティスのエラー追跡システムに記録されます。 なぜ使用するのですか？ これは歴史的遺産であり、マンティスは今から15年間「一緒に」働いています。



何度か同僚に他の何かを見つけるように招待しました。 私たちは分析を開始し、そのたびにマンティスに必要なものがすべて揃っていることがわかりました。 「オープンライン」と技術サポートに関連する作業に完全に統合しました。



Mantisでのエラーに関するお客様からの苦情の全日誌。



各ミニアップデートには、クライアントとテスターが発見した機能とバグ修正が含まれています。



開発者は、エラーが修正されたと主張しています-私たちはチェックします。 エラーが修正されない場合は、チケットを仕事に戻します。



開発者が同じエラーを数回修正できない場合、この非動作部分を更新から削除し、改訂のために開発者に送信します。

第4段階

検証後、テスト計画の繰り返し実行である第4段階に進みます。



市場の状況は変わる可能性があります。 昨日と同じ条件だったら、明日は変わるかもしれません。 6か月前に開発したTKとの密接な結びつきはありません。 したがって、テスト計画を再度実行します。

5段階

5番目のステージは、サービスパックのアセンブリとリファレンステスト環境へのアップロードです。これはAmazonクラウドにあり、個別のBitrix24ポータルです。



ここで、ビジネスシナリオを完成させます。 一連の自動テストはすべて夜間に実行され、インフラストラクチャインジケーターの変化を追跡します。

6段階

第6段階では、非公開のテストグループを編成します。



グループはテスターではなく、実際のクライアントとパートナーです。 これは、製品の実際のユーザーからフィードバックを得るためです。 彼と直接仕事をする人。



この段階までに、ほとんどすべてのエラーがすでに捕捉されています。 ユーザーは、さまざまなシナリオで作業することがいかに便利かを伝えます。 この追加のユーザビリティテストを呼び出すことができます。

7段階

次に、第7ステージのターン-準クローズドテスト：



原則として、私のFacebookでは、私たちの新製品を最初にテストするように顧客を招待しています。 誰でも参加できます 。無料で、 私に書いてください 。



準クローズドテストには、ステージ環境があります。 参加を希望する顧客のポータルが追加されます。 通常、数千のポータルを募集しますが、それはすべて更新の規模に依存します。



ここでは、製品の操作の利便性、スクリプトの利便性も評価します。



時々自明ではないように思われることもあり、前の段階では、パートナーはこれを行うべきではないと書いています。 そして、この段階では、より大きな顧客サンプルでソリューションをテストし、仮説をテストすることができます。



この段階には2〜3週間かかる場合があります。 お客様からのフィードバックは常に変更されています。



ステージでテストした後、更新は実稼働にロールアウトされます。 そして、私たちは喜んでトレーニング記事を書いてビデオを撮影します。



Facebook、直接、または公開ページに印象を書くことができます 。 質問をし、意見を述べ、批判します-私は常に建設的であることを歓迎します。

クラウドファースト

多くのお客様は、Bitrix24のクラウドバージョンの更新プログラムを最初にリリースしたことを訴えています。 これまでのところ、クラウドとボックスの両方の更新を同期的にリリースするような方法で、テストプロセスを構築して製品をリリースすることはできませんでした。



ボックス更新リリースは、より複雑なプロセスです。 生の製品の実行に精通している場合は、テスト環境とは何かを知っています。 クラウドには、独自のエンコーディングを備えたPHPとMySQLの特定のバージョンを備えた既製のインフラストラクチャが既にあります。 すべてがセットアップされ、動作しています-製品をインストールして、安全にテストできます。



「ボックス」では、すべてが異なります。 顧客間の「環境」のばらつきは非常に大きいです。 私たちはユーザーにPHPのより高いバージョンへのアップグレードを奨励しようとしていますが、多くはそうすることに消極的です。



実際、クライアントの大部分は、ホスティング業者に強制された場合にのみPHPのバージョンを変更し始めます。 これに、さまざまなMySQLバージョンとエンコーディングを追加します。



そのため、ボックステストは非常に難しく、長くなります。

自動テスト

上記では、手動テストプロセスについて詳しく説明しましたが、これはプロセス全体の一部にすぎません。 同様に重要な役割は、セルフテストによって果たされます。



自動テストは特別な部門によって作成されます。



以前は、すばらしいスクリプトプロジェクトを作成していました。 そして、これらのシナリオは相互に関連していました。 しかし、短期間で製品に大量の変更が加えられた場合、それらを維持するのは困難です。



したがって、大規模なスクリプト化された自動テストを小さな独立したスクリプト、ケースに分割しました。



自動テストを使用するには、自己記述型の.NETフレームワークと、データベースを操作するための別のフレームワークが必要です。



PHPに製品があり、.NETに自動テスト用のフレームワークがあるのはなぜですか？



私の長年の経験では、動作するフレームワークはUIの自動テストに適しています。 .NETを使用するのは、UIに完全に接続し、Seleniumでうまく機能するためです。



平均的な自動テストはどのように行われますか？

• インターフェイスをバイパスして、APIを介してスクリプトをチェックするためのテストインストールを準備します
• ロボットは指定されたケースをチェックします。 たとえば、タスク。

データクレンジングでも同じことが言えます。 スクリプトをチェックアウトしました。 すべてが順調であれば、インターフェイスではなくAPIを介してタスクを削除します。タスクを削除するためのメソッドを呼び出します。 ロボットは、その背後にあるデータをすばやくクリーンアップします。



以前は、インターフェイスを介してのみテストしました。



インターフェースをクリックするほど良いと考えられています。 しかし、前例でのテストは今日重要であるため、これを残しました。

煙テストと夜間自動テスト

また、煙テストも実施しています。 非常に高速に動作し、最上位の最も一般的なビジネスシナリオを確認します。



通常、最終チェックに使用します。



大規模なテスト、大規模な反復、更新の大規模なパッケージのプロセスに戻る場合、パッケージを参照環境に「配置」します。 そして夜には、スケジュールされた自動テストが実行されます。 全員が寝ており、ロボットは指定されたシナリオをクリックします。



夜間の自動テストの完全なサイクルがようやく夜間に収まり始めました。 以前は約32時間かかりました。 自動テストは、仮想マシンの助けと、フレームワークとテスト自体の絶え間ない最適化によって加速されました。



しかし、テストプロセスにないのは、絶え間ない統合です。 蓄積された「歴史的遺産」があるので、私たちには向いていません。



非常に大きく複雑なインフラストラクチャの一部を拒否することはできません。 そのため、今のところ、古典的な連続積分の小さな要素を導入しようとしています。

夜の集会

ボックス版ユーザーは、3か月ごとに新しいディストリビューションをリリースすることを知っています。 また、3か月間、新しいアセンブリが毎晩自動的に組み立てられ、レイアウトされます。



これはどうですか？



自己記述システムは、更新コレクターを呼び出し、可能なすべての更新を自動的に配置します。 インストール段階で落ちたように見えます。



その後、マシンは利用可能なすべてのディストリビューション（8つあります）を収集し、夜間にローカルインストールを展開します。



パブリックドメインにナイトビルドを投稿しません。 システムは、すべてがインストールされているかどうかを再度キャプチャします。 すべてが正常な場合、すべての自動テストが実行されます。



午前中、テスターはログをチェックし、どこで何が落ちたか、開発者がミスを犯した場所、自動テストを修正する必要がある場所を調べます。

単体テスト

テストのほとんどは、ユニットではなくUIです。 単体テストは、メインモジュール、CRM、オンラインストアなどの重要なコンポーネントに対してのみ使用します。



一部の企業では、誰が単体テストを作成すべきかについて意見の相違があります。



私の意見では、テスターと開発者の両方がそれらを書くことができます。 彼らが開発者によって書かれたことがたまたま起こりました。



単体テストを実行するには、標準のPHP単体ツールを使用します。 メソッドを呼び出すだけです。 入力で指定されたパラメーターでどのように機能するかを確認します。 そして答えを見てください。

URLチェッカー

これは私の古い考えです。 おそらくそれは誰かに役立つでしょう。



エントリーロボット：

• サイトのルートURLを取得し、
• すべてのページのURLを収集します
• 彼はそれらに従い、どこでエラーが発生するかを確認します。

可能なエラーの既製リストがあります：404エラー、致命的なエラー、データベースエラー、JSエラー、無効な文字、壊れた画像、500エラー。



見つけてページコードから引き出すことができるものすべてを、ロボットはスクリーンショットでログに追加します。



このようなロボットの作成は非常に簡単ですが、多くの時間を節約できます。

コンポーネントチェッカー

コンポーネントチェッカーは次のように機能します。

• コンポーネントがページに配置されます
• 保存、更新されます。
• テキスト形式とコードで表示されるものを見る

Web開発のための効率的で簡単なテスト。



あなたが私たちのパートナーであり、モデレートのためにMarketplaceのモデレーターにモジュールを提供したことがある場合、このチェッカーですべての決定を確実に実行することに注意してください。

視覚実験

現在、小さな実験を行っています。テスト計画をテキストから視覚的なスキームに移行しています。 接続図に似ています。



製品のどの要素が何に関連しているのかを即座に表示します。注文の保管によって何が影響を受けるのか、あるいは保管自体に何が影響するのか？ 株式会計のスキームにどのような影響を与えることができますか？



そのため、テスターは特定のコンポーネントの変更によってどの要素が影響を受けるかを迅速に評価できます。

テスト品質

冗長なテストを拒否しました。 私は十分性の原則を支持しています。



現在、「ばかからの保護」についてはほとんどテストしていません。 たとえば、お金の入力フィールドには、ほとんどの場合、文字を入力しません。



一部の企業はこれを実践しています。 一部の人々は、優れたテスターは、規定されたテストケースに限定する義務はないと考えています。 彼はちょうどそれらを構成することができます。



しかし、私たちにとって、このアプローチは機能しなくなりました。現実には、「十分な」テストで十分です。



十分性は、市場のニーズと製品のリリースのタイミングによって決まります。 新しい機能は1年でテストできますが、リリースに遅れることがあります。



したがって、私たちは十分性の原則に従います。 市場から追い出されているため、生の製品は生産していません。 そして、リリース時に時代遅れになるなめられた機能のリリースで引っ張っていません。



* * *

あなたが読んだものについてのあなたの意見に興味があります。 あなたの会社でテストはどのように行われていますか？