テスターとして、私たちは皆、多かれ少なかれ自動化について聞いたり、使用したりしたことがあります。私たちが最初にテスト業界に入ったとき、私たちは期待に満ちていて、テストの終わりはテスターがクリックする必要がなくなることだと考えていました。切り替えれば、テスト作業は瞬時に完了します。
私が開発からテストに切り替えた当初、最も興味があったのはこれでした。この好奇心を持って、社内に新設された自動化グループに熱心に参加し、テストで手作業をなくし、テストを完了する方法を模索しました。6 年かかりました。それをするために。
次に、社内でオートメーションを使用するプロセスを 1 つずつ紹介します。これが皆さんのインスピレーションと助けになれば幸いです。
自動スタート
自動化チームを構築するすべての企業は間違いなく、自動化によって作業効率を向上させ、時間を節約し、人員を節約したいとは考えていないと思います。
しかし致命的な点があり、初めて自動化を立案する人の多くは、自動化の本質や特徴を全く理解しておらず、「自動化によって他社と同じように効率化ができる」ということしか知らない人が多いのです。真実を知ってから何年も。
これは誰かを批判したり非難したりするわけではなく、どのようなアプローチが可能で何が不可能なのかを深く理解することができ、人生の一歩一歩を無駄にせずにこの3年間を過ごせたことにとても感謝しています。
私がここでこれを言ったのは、後から参入した人が理解するのにそれほど時間はかからないからであり、意思決定を行う前に自動化についてより包括的に理解してほしいと願っています。
2016 年に、リーダーがテスト部門で自動化を行うべきだと決定しました。当時、私は開発からテストに切り替えて間もなく、まだ機能テストを行っていました (機能テストの経験段階)。自動化分野の関連資料を参照してください。
そのため、リーダーが自動化グループを設立すると言ったとき、私はついにこの新しい自動化ガジェットを実際に試す機会が来たと思い、非常に興奮し、自動化グループに参加することを決めました。
開発スキルは低いですが、結局自動化と実際に戦ったことがないので、外部から自動化の方向で大きな牛を採用しました。
テクノロジー大手は違います。自動化プロジェクト アーキテクチャを構築し、関連パッケージの抽出を実行するのにわずか 2 週間しかかかりませんでした。当時、私は Selenium、Webdriver、TestNg、Jenkins と統合された自動化システムのワークフローと使用法をよく知っていました。
これを書いた後、私たちが実装したのは一連の UI 自動化ソリューションであることはすでにご存知でしょう。フレームワークが構築できたら、残りはユースケースの収集とスクリプトの変換を始め、いわゆる自動テストがどのように自動化されるのかを少しずつ学んでいくのもスクリプトを書く過程でした。
自動化の初期の頃、私たちにはあまり経験がなく、少なくともパブリックのメインプロセスのユースケースを自動化する必要があることだけを知っていました。
そこで、数か月にわたる機能テスト後のビジネスの理解に基づいて、特定のモジュール タイプのユース ケースを抽出し始めました。技術専門家と私は分業してこれらのユース ケースを変換しました。このプロセスで私は学びましたPO モード、データ ドライブ、要素の配置、および内部の落とし穴についてはよく知っています。
スクリプトの作成は私にとって簡単に始めることができます。すぐに自動化ユース ケースのフェーズが完了し、これらのユース ケースを Jenkins に統合しました。これまでのところ、自動化が機能し始めています。
自動化の意味を探る
第 1 フェーズのスクリプト変換が完了した後、第 2 フェーズのスクリプト開発計画がノンストップで開始されました。自動化する意味がなくなってきたと長い間感じていましたが、せっかくスクリプト開発が完了したのに、使ってみませんか？仕事にどうやって使えますか?
自分のやっていることが仕事で価値を発揮していない場合、その仕事をしている人は、フィードバックを受けられず、次の目標がどこにあるのかも分からないため、徐々にこの仕事に対する熱意を失っていきます。もちろん、一部の必要不可欠な作業は引き続き行われます。
翌年、つまり 2017 年に、リーダーは私たちと一緒に方法を考え始めました。最初の方法は、機能テスターにどのモジュールとユースケースを自動化したかを伝え、テスト プロセス中にテストしてもらうことでした。そのタイプのユースケースを実行するには、Jenkins に移動して実行します。
一定期間の試行では、無償かつ自発的な手段に頼って良い仕事をするのは不可能であることが証明されました。
たとえ彼のプロジェクトでは自動化が可能だったとしても、ほとんどの人は自動化の使用を選択しません。開発関連テクノロジが分からず、間違いを犯した場合に問題を分析する方法も分からないため、喜んで使用する学生もいます。そのため、支援してくれる自動化開発者を見つける必要がよくあります。さらに、初期段階の UI 自動化スクリプトは実際にはあまり安定しておらず、エラーが実行される可能性はさらに高くなります。
自動化する必要がない理由は次のとおりです。
1. 興味がない、手動テストが良いと思う
2. 使ってみたいが、自分の技術が足りず、スクリプトの問題点を解析できないので使いにくい 3. 使ってみ
たい, しかし、スクリプトの安定性があまりにも悪すぎて、自動化の信頼性に自信を失います。
他の同僚と比べて、私は自分自身を自動化の愛好家だと考えており、私の仕事において自動化が役割を果たせないとは考えていません。それは自分自身が使い方を知らないからではないかと思いました。そこで、一定期間自動化されたアプリケーションモジュールに適したテストを申し込みました。
どうすればいいのですか？以下は、通常のプロジェクトのテストにおける自動適用のフローチャートであり、私はこのアイデアを現在でも使用しています。
このプロセスに従って、いくつかのプロジェクトがつまずきながら申請されました。実際の効果は次のとおりです。
1. 自動化を導入した結果、確かにいくつかの問題が見つかったが、分析と位置付けの結果、それは目に見えないバグであることが判明した; 2. 効率の観点から、投入コスト/生産量を考慮すると、これ
は改善されたとは言えない テスト効率はかなり良いが、スクリプトを複数人で開発・保守する場合は別; 3.
Jenkins上でユースケースを実行するのはあまり便利ではなく、見るのがめまいがすることが多い。
実際に自社の自動化に参加して初めて、自社の自動化には不完全な点が多々あることが分かり、次にどこを調整すればよいのかも分かりました。
自動化されたソフトウェア テスト エンジニアとして、すぐに優れたテスト開発リーダーになるためには、どれくらい頑張ればよいでしょうか? これは、職場に足を踏み入れたばかりのソフトウェア テスト エンジニアだけでなく、3 年働いて混乱し始めるエンジニアも同様です。 5 年間に直面し、理解しなければならない問題。
1. 最初にプログラミング言語を学びます。Python が推奨されます [以下に示されていないすべての学習ロードマップのオリジナル マップを含む、すべての写真が示されているわけではないことに注意してください。必要な友人は、私の学習交換グループに参加して無料で入手できます。 】
2. Web自動テストの基礎
3. Web 自動テストの実践 
4. APP自動化の基本
五、APP自動テスト実践
6. APIインターフェース自動化の基本
七、APIインターフェース自動化テスト実戦
八、CI/CD継続的統合特殊技術
9、自動テストフレームワークプラットフォーム
自分の学びと向上のために、毎分、毎秒の時間を適切に活用し、思考の怠惰を隠すために「時間がない」ということを使うのはやめましょう。若いうちは頑張って将来の自分に説明を与えてください！
10. 情報
これらの資料は、[ソフトウェア テスト] を行う友人にとって、最も包括的で完全な準備倉庫となるはずです。この倉庫は、私が最も困難な旅を乗り越えるのにも同行してくれました。そして、あなたにも役立つことを願っています。何事もできるだけ早く行うべきであり、特に技術産業においては、技術スキルを向上させなければなりません。 お役に立ちましたら、いいね、収集をお願いいたします。次回もすぐに探せて便利です
一人で大幅に成長したくない場合、システム情報が見つからない場合、問題のサポートが得られない場合、数日間粘っても諦めた場合は、下の [小さなカード] をクリックしてテクニカル サポートに参加できます。交流グループでは、誰もが一緒に議論したりコミュニケーションしたりすることができ、さまざまなソフトウェアテスト資料や技術交流が行われます。最後に、できるだけ早く皆さんに満足のいくオファーを提供できることを願っています〜
